Can we get back the overload that consumes a configuration section? We want to systematically enable things to be configured in this way and it's the convention in this repo.

Can we call all the configuration delegate just "configure" which is the convention we use in this repo?

Thanks.

Currently looking into why the section was removed after aspnetcore api-review, they had some arguments that might be worth checking.

configureOptions: there are a few occurrences in this repos in case you think it's worth going through the rest of the code for consistency.

@geeknoid This is like a custom deserialization for these settings. I see that it's checking the value is a valid integer, what else is it providing over the standard configuration methods?

So yes, we should change "configureOptions" to "configure" for general consistency.

Within this repo, we generally use a triplet of functions for configuring components. No options (you get the defaults), an Action delegate which lets you override options, and a ConfigurationSection to make it easy to consume the configuration state from an external JSON. This model has been working well for us.

@tekian Jan helped establish this pattern 3 years ago or so, maybe he has additional insights to provide.

With respect to configuration section, we make no assumptions about where in the configuration hierarchy is the section to configure the component. We let developer decide and hand us the section to bind to. IConfigurationSection, as compared to IConfiguration, knows Path which was an information we wanted to capture to be able to reconstruct configuration schema.

Thats fine but 90% of our code takes IConfiguration, not IConfigurationSection and it usually parses a known schema (more than just an int). The pattern should be consistent with the rest of the APIs in the stack.

Given that this is now in the general-purpose Microsoft.Extensions.ObjectPool namespace, perhaps we should give this a more specialized name? ServiceCollectionPoolOptions maybe? Any other ideas?

This one is hard, DependencyInjectionPoolOptions? But the current name loks fine to me, there is no conflict and users will probably not use the class name directly.

Why didn't this get called ObjectPoolOptions?

I agree with Martin. It looks strange, that this type (or ObjectPoolOptions) is not used by Microsoft.Extensions.ObjectPool || Microsoft.Extensions.ObjectPool<T>.